Add RFC 4771 Roll-over Counter Carrying (RCC) support — modes 1, 2 and 3

Summary

This PR implements the RFC 4771 Roll-over Counter (ROC) Carrying integrity transform for SRTP. It lets a sender periodically embed its 32-bit ROC in the SRTP authentication tag of selected packets, so a late-joining or re-synchronizing receiver can recover the correct ROC without having to guess it from the RTP sequence number. All three RFC 4771 modes are supported, with mode 3 layered on top of the AES-GCM AEAD transform per RFC 7714 §8.2.

RCC is opt-in and fully backward compatible: streams that do not enable it (srtp_rcc_mode_none, the default) behave exactly as before and use the standard RFC 3711 implicit-ROC transform.

Motivation

Under RFC 3711 the ROC is never transmitted; a receiver infers it from the RTP sequence number. A receiver that joins mid-stream, loses synchronization, or misses a sequence-number wrap can end up with the wrong ROC and fail authentication on every subsequent packet. RFC 4771 solves this by carrying the ROC in-band on a configurable subset of packets ("ROC-carrying" packets, those whose RTP sequence number is ≡ 0 (mod R)).

What's implemented

• Mode 1 — Only ROC-carrying packets are integrity-protected; other packets carry no authentication tag.
• Mode 2 — ROC-carrying packets use the RCC tag; all other packets use the standard integrity transform. (Most common / robust choice.)
• Mode 3 — NULL-MAC variant: the transform carries only the 4-octet ROC with no MAC of its own. Supported on top of AES-GCM (RFC 7714), where the AEAD tag authenticates the packet and the ROC feeds the GCM IV.

For a ROC-carrying packet in modes 1/2, the tag is built as:

TAG = ROC (4 octets) || MAC_tr

where MAC_tr is the (auth_tag_len - 4) most-significant octets of the HMAC-SHA1. This requires auth_tag_len >= 5.

Packet layout

Modes 1/2 (AES-CM + HMAC-SHA1), ROC-carrying packet:

[ RTP header ][ encrypted payload ][ MKI (optional) ][ ROC(4) || MAC_tr ]

Mode 3 (AES-GCM, RFC 7714 §8.2), ROC-carrying packet:

[ RTP header ][ ciphertext incl. 16-octet GCM tag ][ MKI (optional) ][ ROC(4) ]

The 4-octet ROC is the SRTP authentication-tag field and is placed after the MKI. It is not part of the GCM AAD (AAD remains the RTP header only); instead the ROC feeds the GCM IV, so any tampering with the carried ROC produces a wrong IV and a GCM authentication failure — giving implicit integrity protection of the ROC.

API changes

New public enum and function in include/srtp.h:

typedef enum {
    srtp_rcc_mode_none = 0,   /* default RFC 3711 transform */
    srtp_rcc_mode_1    = 1,
    srtp_rcc_mode_2    = 2,
    srtp_rcc_mode_3    = 3
} srtp_rcc_mode_t;

srtp_err_status_t srtp_policy_set_rcc_mode_tx_rate(
    srtp_policy_t policy, srtp_rcc_mode_t rcc_mode, uint16_t roc_tx_rate);

• roc_tx_rate (R) is the transmission rate; R == 1 carries the ROC in every packet. Must be >= 1 when RCC is enabled.
• Both peers must derive the same mode and rate so they agree on the packet layout.
• Validation enforces cipher/mode consistency: modes 1/2 require an AES-CM profile and auth_tag_len >= 5; mode 3 requires an AES-GCM profile. Inconsistent combinations are rejected by srtp_create() / policy validation.

Implementation notes

• Modes 1/2 are handled by dedicated srtp_protect_rcc() / srtp_unprotect_rcc() paths in srtp/srtp.c.
• Mode 3 is handled inside srtp_protect_aead() / srtp_unprotect_aead(), since GCM dispatch happens ahead of the RCC dispatch.
• On a ROC-carrying packet the receiver adopts the sender's ROC (srtp_rdbx_set_roc_seq() + re-anchoring the replay index); non-carrying packets use the normal estimated packet index and replay check.
• MKI lookup: because the ROC now follows the MKI in mode 3, the unprotect dispatch passes srtp_len - 4 for ROC-carrying packets so the existing "MKI is last" lookup still locates the MKI correctly. Carry-packet detection uses only seq % R == 0 and the configured mode (no session keys required).

Testing

Added test/rcc_test.c covering:

• Modes 1 and 2 round-trip protect/unprotect (AES-CM + HMAC-SHA1).
• Mode 3 round-trip over AES-GCM.
• ROC recovery on a receiver starting from a mismatched ROC.
• Tamper detection for mode 3 (modifying the carried ROC yields srtp_err_status_auth_fail).

All tests pass. Mode 3 tests require a build with GCM enabled (-DENABLE_OPENSSL=ON).

Backward compatibility

• Default behavior is unchanged: srtp_rcc_mode_none streams use the standard RFC 3711 transform.
• No changes to existing wire format for non-RCC streams.
• New API is purely additive.

Limitations / open items

• Modes 1/2 are defined only for AES-CM ciphers; mode 3 only for AES-GCM (matching the RFCs).
• RCC applies to SRTP (RTP); SRTCP is unaffected.